經過了三天的文章後,我們總算要進到新的『 Compare 』篇章了。
前兩天我們介紹了 WYSIWYG 一詞本身所代表的涵意,並列舉了一些市面上知名的應用,並接著介紹了瀏覽器提供的 contenteditable
屬性以及 execCommand
api ,以及它們並不適用於現今的網頁開發技術的原因。
還沒閱讀的讀者們, 傳送門在此~
在 Compare 篇章裡會不時的提到上述的這些內容,因此先認識這些名詞能幫助讀者更容易消化之後的文章。
延續上一篇不同 『世代』 的編輯器的議題,我們可以大致上為網頁編輯器分成 G1 、 G2 、 G3 這三個世代。
第一世代的編輯器選擇大幅度地依賴在 contenteditable
屬性上,主要負責處理跨瀏覽器的相容性問題,提供的 api 也更貼近於使用 execCommand
api 的語法糖,也有些選擇放棄 execCommand
api 自己實作一套命令代替原本的功能操作 DOM 元素。
但總歸而言主要還是依附在 contenteditable
屬性與 HTML Document 上去實作。
開發者不需要太多相關於 WYSIWYG 編輯器的底層知識,只要綁好指定的 DOM element 、做好 init 、再把 library 提供給開發者的擴充套件裝一裝就可以直接使用了。
它們更像是直接將套件提供的,架構早已定死的編輯器拿來使用在自己的 web 應用上,編輯器的功能幾乎都是由 library 提供的,開發者能做的幾乎只有調調參數、裝載套件去選擇功能,頂多再調個外觀,而不是自己手動新建一個編輯器。
到了第二世代以後的編輯器主要依賴於自定義的 Data Model ,而不直接依賴於 DOM ,比起思考如何填補 contenteditable
所帶來的缺口,它們更將重點放在自定義的 Data Model 與 DOM 之間的資料轉換與操作行為,比如:
這個世代的編輯器依舊會使用 contenteditable
當作與使用者互動的介面,提供給編輯器當前的光標位置、 User 的反白位置與當前活動的區域,差別就在於儲存的資料格式與中間的轉換行為是自定義的。
目前市面上大多數的 WYSIWYG 套件都屬於這個世代的,只是它們的實作方式與定位又能進一步將它們區分開來,這也是我們主要在這個篇章會探討的主題。
再來到了第三世代的編輯器,Google Docs 幾乎從頭到尾捨棄了瀏覽器的支援,在第二世代的編輯器裡還看得到以 contenteditable
作為與使用者互動的介面提供編輯器部分的資料,但到了這邊已經完全被拔除了。
Google Docs 建立了自己的一套編輯界面( editing surface )與渲染引擎( layout engine ),對於瀏覽器來說,Google Docs 提供的編輯器完全就只是一個由 Javascript 處理一切動態效果的頁面。
它完全不依賴於瀏覽器提供的光標與使用者反白等資訊,而是透過編輯界面去動態計算滑鼠點擊位置在畫面上的 x 與 y 軸,並畫出一塊 div
tag 來代表光標元素,反白資訊也是以相同的方式去製作。
至於文字與其他資料的相關呈現則依靠渲染引擎,透過計算文字的長與寬等資訊結合當前光標的 x y 軸資訊去計算出例如:新安插的文字的擺放位置。
對這些資料感興趣的讀者可以參考 Google Drive Blog 撰寫的 這篇 介紹新版 Google-Docs 的文章。
其他還有像 ICloud Page 也屬於這個世代的編輯器,但因為這一世代相關的專案都並非開源專案,這也需要足夠龐大的人力與精力才有辦法踏進這池深水,所以筆者也沒有做太多功課,在整篇系列文章中也不會多做介紹。
在了解了各個世代的編輯器各自的特色以後,我們接下來會順著時間軸依序將一、二世代中不同編輯器 library 與 slate.js 做比較。
分別是 G1 的 CKEditor 與 TinyMCE ,以及 G2 的 Quill 以及 Draft 還有最後的 Slate。
其實市面上有非常多優秀的 libraries 是值得拿出來介紹的,像 ProseMirror 原本也是筆者在這篇系列文章的目標之一; Froala 也是筆者在準備整篇系列文章時查到,近期討論度頗高的一個,只可惜時間有限,心有餘而力不足之下還是只能縮限介紹的範圍,未來有機會再補上這些內容。
那今天就到這邊拉 ~ 明天 G1 見!